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of a plurality of join indexed. The join indexes are defined 
for a table stored in the database. The join indexes are 
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wherein one or more common joins are identified among the 
join indexes, each of the common joins are materialized only 
once in a common spool file, and the common spool file is 
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COMMON SPOOL FILES FOR data is being selected. The subset of data is treated as a new 

MAINTAINING JOIN INDEXES table, termed the result table. 

A join operation is usually implied by naming more than 

CROSS REFERENCE TO RELATED one table in the FROM clause of a SELECT statement. A 

APPLICATIONS 5 join operation makes it possible to combine tables by 

_ . .... . . . e .. combining rows from one table with another table. The 

Tins application is related to the following co-pending or * ortions 0 f r0WS , from the different tables are 

and commonly assigned patent applications, all of which are concate J ed horizontaUy . Mlhough not requirea> join 

incorporated by reference herein: operations normally include a WHERE clause that identifies 

Application Ser. No. 09/073,113, entitled "A JOIN 30 the columns through which the rows can be combined. The 

INDEX FOR RELATIONAL DATABASES", filed on WHERE clause may also include a predicate comprising one 

May 5, 1998, by Chi Kim Hoang, now U.S. Pat. No. or more conditional operators that are used to select the rows 

6,167,399, issued on Dec. 26, 2002. tQ ^ j 0 i ned 

Application Ser. No. 09/594,963, entitled "VIRTUAL j oin ibexes have been used to improve the performance 

JOIN INDEX FOR RELATIONAL DATABASES", is of join operations in an RDBMS. A description of join 

filed on Jun. 15, 2002, by Ahmad Ghazal, Paul Sinclair, indexes, including a novel join index, can be found in 

and Chi Kim Hoang, and co- pending and commonly-assigned application Ser. No. 

Application Ser. No. 09/594,964, entitled "AGGREGATE 09/073,113, filed on May 5, 1998, by Chi Kim Hoang, 

JOIN INDEX FOR RELATIONAL DATABASES", entitled "A JOIN INDEX FOR RELATIONAL 

filed on Jun. 15, 2000, by Grace K. Au and Chi Kim 20 DATABASES", which application is incorporated by refer- 

Hoang. ence herein. 

Join indexes are automatically maintained by the RDBMS 

BACKGROUND OF THE INVENTION when updates m performed on the underlying tables. 

1 Field of the Invention Usually, additional steps are included in the execution plans 

_ . . . 4 . A . . . , 25 for these updates to regenerate the affected portions of the 

This invention relates in general to computerized rela- ■ • ■ j t ,u *u * a « *u • • 

, , . t , ... r loin indexes. In many cases, the queries that define the join 

tional databases, and in particular, to the use of common J . . , , u i ■ i . a * t u n n 

, ~, r ' ♦ e • ■ • j indexes have to be re-processed in order to update the join 

spool files for the maintenance of join indexes. . . r r J 

r J mdexes. 

2. Description of Related Art WheQ thefe m a ^ number of join in dexes defined on 

Relational DataBase Management Systems (RDBMS) 30 a table, the overhead of maintaining the join indexes can be 

using a Structured Query Language (SQL) interface are well quite high ThuSj there is a nee d in the art for techniques that 

known in the art. The SQL interface has evolved into a minimize the overhead involved in performing maintenance 

standard language for RDBMS software and has been on j 0 ^j indexes, 
adopted as such by both the American National Standards 

Institute (ANSI) and the International Standards Organiza- 35 SUMMARY OF THE INVENTION 

tion.(ISO). j 0 overcome the limitations in the prior art described 

In an RDBMS, all data is externally structured into tables. above, and to overcome other limitations that will become 

A table in a relational database is two dimensional, consist- apparent upon reading and understanding the present 

ing of rows and columns. Each column has a name, typically 4Q specification, the present invention discloses a method, 

describing the type of data held in that column. As new data apparatus, article of manufacture, and data structure related 

is added, more rows are inserted into the table. A user query to the maintenance of a plurality of join indexes. The join 

selects some rows of the table by specifying clauses that indexes are defined for a table stored in the database. As the 

qualify the rows to be retrieved based on the values in one table is updated, queries that define the join indexes are 

or more of the columns. 45 re-processed to obtain the records for updating the join 

The SQL interface allows users to formulate relational indexes, wherein one or more common joins are identified 

operations on the tables either interactively, in batch files, or among the join indexes, each common join is materialized 

embedded in host languages such as C, COBOL, etc. Opera- only once in a common spool file, and the common spool file 

tors are provided in SQL that allow the user to manipulate is used to materialize one or more rows for updating the join 

the data, wherein each operator performs functions on one or 50 indexes. 

more tables and produces a new table as a result. The power BRIEF DESCRIPTION OF THE DRAWINGS 
of SQL lies in its ability to link information from multiple 

tables or views together to perform complex sets of proce- Referring now to the drawings in which like reference 

dures with a single statement. numbers represent corresponding parts throughout: 

The SQL interface allows users to formulate relational 55 FIG. 1 illustrates an exemplary hardware and software 

operations on the tables. One of the most common SQL environment according to the preferred embodiment of the 

queries executed by the RDBMS is the SELECT statement. present invention; 

In the SQL standard, the SELECT statement generally FIG. 2 illustrates the structure of two base tables and join 

comprises the format: index according to the preferred embodiment of the present 

"SELECT<cIause>FROM<clause>WHERE<clause>GROUP 60 invention; 

BY<clause>HAVING<clause>ORDER BY<clause>." The FIG. 3 is a flowchart illustrating the steps performed by 

clauses generally must follow this sequence, but only the the RDBMS in collecting information to facilitate the pro- 

SELECT and FROM clauses are required. cess of finding common joins; 

Generally, the result of a SELECT statement is a subset of FIGS. 4A and 4B together are a flowchart illustrating the 
data retrieved by the RDBMS from one or more existing 65 steps performed by the RDBMS in identifying and con- 
tables stored in the relational database, wherein the FROM structing common joins using the information collected in 
clause identifies the name of the table or tables from which FIG. 3; and 
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FIG. 5 is a flowchart illustrating the steps performed by 
the RDBMS in using the common spool files generated in 
FIG. 4 to update join indexes. 

DETAILED DESCRIPTION OF THE 5 
PREFERRED EMBODIMENT 

In the following description of the preferred embodiment, 
reference is made to the accompanying drawings which 
form a part hereof, and in which is shown by way of 
illustration a specific embodiment in which the invention 
may be practiced. It is to be understood that other embodi- 
ments may be utilized and structural changes may be made 
without departing from the scope of the present invention. 

Overview 15 

The present invention describes join indexes, which pro- 
vide dramatic performance improvements to queries that 
involve join operations. The key concept introduced by the 
present invention is that, by discovering common joins 20 
among the join indexes that need to be updated, and by 
materializing these common joins only once in common 
spool files, the amount of overhead incurred during the 
maintenance of join indexes can be minimized. 

25 

Environment 

FIG. 1 illustrates an exemplary hardware and software 
environment that could be used with the preferred embodi- 
ment of the present invention. In the exemplary 
environment, a computer system 100 is comprised of one or 30 
more processing units (PUs) 102, also known as processors 
or nodes, which are interconnected by a network 104. Each 
of the PUs 102 is coupled to zero or more fixed and/or 
removable data storage units (DSUs) 106, such as disk 
drives, that store one or more relational databases. Further, 35 
each of the PUs 102 is coupled to zero or more data 
communications units (DCUs) 108, such as network 
interfaces, that communicate with one or more remote 
systems or devices. 

Operators of the computer system 100 typically use a 40 
workstation 110, terminal, computer, or other input device to 
interact with the computer system 100. This interaction 
generally comprises queries that conform to the Structured 
Query Language (SQL) standard, and invoke functions 45 
performed by a Relational DataBase Management System 
(RDBMS) executed by the system 100. 

In the preferred embodiment of the present invention, the 
RDBMS comprises the Teradata® product offered by NCR 
Corporation, and includes one or more Parallel Database 50 
Extensions (PDEs) 112, Parsing Engines (PEs) 114, and 
Access Module Processors (AMPs) 116. These components 
of the RDBMS perform the functions necessary to imple- 
ment the RDBMS and SQL standards, i.e., definition, 
compilation, interpretation, optimization, database access 55 
control, database retrieval, and database update. 

Work is divided among the PUs 102 in the system 100 by 
spreading the storage of a partitioned relational database 118 
managed by the RDBMS across multiple AMPs 116 and the 
DSUs 106 (which are managed by the AMPs 116). Thus, a 6 o 
DSU 106 may store only a subset of rows that comprise a 
table in the partitioned database 118 and work is managed by 
the system 100 so that the task of operating on each subset 
of rows is performed by the AMP 116 managing the DSUs 
106 that store the subset of rows. 65 

The PEs 114 handle communications, session control, 
optimization and query plan generation and control. The PEs 
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114 fully parallelize all functions among the AMPs 116. As 
a result, the system of FIG. 1 applies a multiple instruction 
stream, multiple data stream (MIMD) concurrent processing 
architecture to implement a relational database management 
system 100. 

Both the PEs 114 and AMPs 116 are known as 'Virtual 
processors" or "vprocs". The vproc concept is accomplished 
by executing multiple threads or processes in a PU 102, 
wherein each thread or process is encapsulated within a 
vproc. The vproc concept adds a level of abstraction 
between the multi -threading of a work unit and the physical 
layout of the parallel processing computer system 100. 
Moreover, when a PU 102 itself is comprised of a plurality 
of processors or nodes, the vproc concept provides for 
intra-node as well as the inter-node parallelism. 

The vproc concept results in better system 100 availability 
without undue programming overhead. The vprocs also 
provide a degree of location transparency, in thai vprocs 
communicate with each other using addresses that are vproc- 
specific, rather than node-specific. Further, vprocs facilitate 
redundancy by providing a level of isolation/abstraction 
between the physical node 102 and the thread or process. 
The result is increased system 100 utilization and fault 
tolerance. 

The system 100 does face the issue of how to divide a 
query or other unit of work into smaller sub-units, each of 
which can be assigned to an AMP 116. In the preferred 
embodiment, data partitioning and repartitioning may be 
performed, in order to enhance parallel processing across 
multiple AMPs 116. For example, the data may be hash 
partitioned, range partitioned, or not partitioned at all (i.e., 
locally processed). Hash partitioning is a partitioning 
scheme in which a predefined hash function and map is used 
to assign records to AMPs 116, wherein the hashing function 
generates a hash "bucket" number and the hash bucket 
numbers are mapped to AMPs 116. Range partitioning is a 
partitioning scheme in which each AMP 116 manages the 
records falling within a range of values, wherein the entire 
data set is divided into as many ranges as there are AMPs 
116. No partitioning means that a single AMP 116 manages 
all of the records. 

Generally, the PDEs 112, PEs 114, and AMPs 116 are 
tangibly embodied in and/or accessible from a device, 
media, carrier, or signal, such as RAM, ROM, one or more 
of the DSUs 106, and/or a remote system or device com- 
municating with the computer system 100 via one or more 
of the DCUs 108. The PDEs 112, PEs 114, and AMPs 116 
each comprise logic and/or data which, when executed, 
invoked, and/or interpreted by the PUs 102 of the computer 
system 100, cause the necessary steps or elements of the 
present invention to be performed. 

Those skilled in the art will recognize that the exemplary 
environment illustrated in FIG. 1 is not intended to limit the 
present invention. Indeed, those skilled in the art will 
recognize that other alternative environments may be used 
without departing from the scope of the present invention. In 
addition, it should be understood that the present invention 
may also apply to components other than those disclosed 
herein. 

Join Index 

A join index stores the results from one or more join 
operations on one or more columns of one or more tables, 
wherein the join index combines one or more commonly- 
used columns of the tables. The join index can then be used 
to satisfy a subsequent query, rather than having to perform 
the join operations on columns of the tables referenced in the 
query. 
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FIG. 2 illustrates the structures of two base tables 
(CUSTOMER_TABLE 200 and ORDER_TABLE 202), 
and a join index (JOIN_INDEX 204). 

The base tables 200 and 202 are created using the fol- 
lowing SQL statements: 

CREATE TABLE CUSTOMER_TABLE( 
CUSTKEY INTEGER NOT NULL, 
NAME CHAR(26) CASESPECIFIC NOT NULL, 
ADDRESS VARCHAR(41), 
STATE VARCHAR(2)) 
UNIQUE PRIMARY I NDEX( CUSTKEY); 
CREATE TABLE ORDER_TABLE( 
ORDERKEY INTEGER NOT NULL, 
ORDERSTATUS CHAR(l) CASESPECIFIC, 
ORDERDATE DATE FORMAT 'YYYY-MM-DD* 

NOT NULL, 
PRICE DECIMAL(13,2) NOT NULL, 
CUSTKEY INTEGER) 
UNIQUE PRIMARY INDEX(ORDERKEY); 
A simple query comprising a SELECT statement can be 
defined on the base tables 200 and 202, wherein the query 
performs a join operation: 

SELECT NAME, ORDERDATE 
FROM ORDER_TABLE, CUSTOMER_TABLE 
WHERE ORDER_TABLE.CUSTKEY=CUSTOMER_ 
TABLE CUSTKEY 

AND ORDERDATE>DATE '01-01-2000' 
AND ORDERDATE<DATE '03-01-2000'; 
Without a join index 204, a typical execution plan for this 
query would involve redistributing ORDER__TABLE 202 
into a spool file, sorting the spool file on CUSTKEY, and 
then performing a merge join between the spool file and the 
CUSTOMER_TABLE 200. 

In the preferred embodiment, however, a join index 204 
can be defined as follows: 

CREATE JOIN INDEX JOIN_INDEX 
SELECT ORDER_TABLE. CUSTKEY, 
CUSTOMER_TABLE.NAME, 
ORDER_TABLE.ORDERSTATUS, 
ORDER_TABLE.ORDERDATE 
FROM ORDER_TABLE, CUSTOMER_TABLE 
WHERE ORDER_TABLE.CUSTKEY- 
CUSTOMER_TABLE.CUSTKEY; 
The join index 204 is maintained as a separate table. Each 
entry in the join index 204 includes the specified column 
values, as well as row identifiers (or other pointers) to the 
rows in the tables 200 and 202 with those same column 
values. Thereafter, queries can scan the join index 204, when 
at least a portion of the query can be satisfied by the join 
index 204. 

For example, an execution plan for the above SELECT 
statement may scan the join index 204, in a manner similar 
to that shown in the following statement: 

SELECT NAME, ORDERDATE 

FROM JOIN__INDEX 

WHERE ORDERDATE>DATE '01-01-2000' AND 
ORDERDATE<DATE '03-01-2000'; 

The ability to access the join index 204 rather than the 
tables 200 and 202 provides performance benefits. However, 
maintenance can be costly. That is, the benefits of the join 
index 204 are at least partially offset by the overhead of 
maintaining the data of the join index 204. 

Preferably, the join index 204 is automatically maintained 
by the RDBMS when updates (UPDATE, DELETE, 
INSERT) are performed on the underlying tables 200 and 
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202. In the preferred embodiment, additional steps are 
included in the execution plans for these updates to regen- 
erate the affected portions of the join index 204. 

In many cases, the query that defines the join index 204 
5 has to be re-processed in order to update the join index 204. 
When there are a large number of join indexes 204 defined 
on a table 200 or 202, the overhead of maintaining the join 
indexes 204 can be quite high. The present invention uses 
common spool files to minimize the overhead of mainte- 

,o nance - 

Common Spool Files 

In the preferred embodiment, common joins are identified 
among a plurality of join indexes, the common joins are 
materialized only once in reusable common spool files, and 

15 the common spool files are used to materialize join rows for 
updating the join indexes. The use of common spool files 
minimizes the amount of overhead incurred during the 
maintenance of join indexes. 
The preferred embodiment of the present invention 

20 involves a number of steps. First, information about the join 
indexes, including join conditions, is collected. After the 
information has been collected, the join conditions of each 
join index are analyzed to factor out the "smallest" common 
join, i.e., the join index that involves the smallest number of 

25 tables that are joined by a set of conditions that is a subset 
of the join conditions that define one or more other join 
indexes. The smallest common join is materialized into a 
common spool file. This common spool file is used to 
replace the base tables of those join indexes that can use the 

30 common join. This process is repeated until no more com- 
mon joins can be found, e.g., iteratively analyzing the 
remaining join conditions of each join index to factor out the 
next "smallest" common join that involve the smallest 
number of tables and the smallest set of join conditions, 

3 5 materializing the next smallest common join into another 
common spool file, and using this common spool file to 
replace the base tables of the remaining join indexes. The 
rows for each join index are materialized from the common 
spool files and then used to update the join indexes. 

40 Logic of the Relational Database Management 

System 

Flowcharts which illustrate the logic of the RDBMS in 
creating and using common spool files to maintain join 
indexes according to the present invention are shown in 

45 FIGS. 3, 4A, 4B, and 5. Those skilled in the art will 
recognize that this logic is provided for illustrative purposes 
only and that different logic may be used to accomplish the 
same results. 

5Q Information Collection 

FIG. 3 is a flowchart illustrating the steps performed by 
the RDBMS in collecting information to facilitate the pro- 
cess of finding common joins. 

Block 300 represents the RDBMS constructing a common 

55 table list that contains all the base tables from all the join 
indexes. In this Block, each unique base table is stored only 
once and assigned a relation number that is equal to its 
position in the list. 
Block 302 represents the RDBMS constructing a common 

60 condition list that contains all the conditions from all the join 
indexes. Each unique condition is stored only once and 
assigned a condition number that is equal to its position in 
the list. 

Block 304 is a decision block that represents the RDBMS 
65 looping through each join index. For each iteration, control 
transfers to Block 306; upon completion, control transfers to 
FIG. 4A. 
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Block 306 represents the RDBMS assigning the set of Block 420 represents the RDBMS adding restrictions to 

relation numbers from the common table list that comprise the common join, if the common join includes the base table 

the base tables for this join index. that is being updated and some restrictions on the table are 

Block 308 represents the RDBMS assigning the set of specified in the user's update request, 
condition numbers from the common conditions list that 5 Block 422 represents the RDBMS building the assign- 
comprise the conditions for this join index. ment list of the common join so that it includes fields of the 

Block 310 represents the RDBMS saving outer join common tables from the select list and from the residual 

conditions in the common condition list. In addition, this term list. These lists are mapped to refer to fields of the 

Block links together outer join terms of this join index in a common spool. 

list and a pointer to this list is saved in a data structure 10 Block 424 represents the RDBMS building the common 

associated with the join index. spool file. 

Block 312 represents the RDBMS initializing the join Block 426 represents the RDBMS adding the common 

index to indicate that it is eligible for common join process- spool file relation to the common table list, 

ing. is Block 428 represents the RDBMS modifying the residual 

Thereafter, control returns to Block 304. term list and the relation set of each join index that can use 

Common Join Identification and Construction the common join to refer to the common spool file relation. 

FIGS. 4A and 4B together are a flowchart illustrating the Thereafter, control transfers to FIG. 4A via "B". 

steps performed by the RDBMS in identifying and con- Using Common Spool Files to Update Join Indexes 

structing common joins using the information collected in 20 FIG. 5 is a flowchart illustrating the steps performed by 

FIG. 3. the RDBMS in using the common spool files resulted from 

Referring to FIG. 4A, Block 400 represents the RDBMS FIGS. 4A and 4B. After all possible common joins have been 

finding the next eligible join index that has the least number materialized and joins on base tables of the join indexes have 

of relations. If multiple join indexes having the same least been replaced by joins on these common spool files, if any, 

number of relations are found, the one with the least number 25 execution plans are generated to update each join index as 

of join conditions is picked. A common join must be a described below. 

complete join of at least one join index. Block 500 represents the RDBMS appending conditions 

Block 402 is a decision block that represents the RDBMS from the user's update request into the join index's 

determining whether there is a next eligible join index. If so, condition, if there exists any that have not been incorporated 

control transfers to Block 404; otherwise, no more eligible 30 into the common spool yet. 

join indexes can be found and control transfers to FIG. 5. B lock 502 is a decision block that represents the RDBMS 

Block 404 represents the RDBMS finding all other join determining whether rows are being inserted into the base 

indexes that have at least all the join conditions of the join table. If so, control transfers to Block 504; otherwise, control 

index found in Block 400 above. transfers to Block 510. 

Block 406 is a decision block that represents the RDBMS 35 Block 504 represents the RDBMS materializing rows for 

determining whether any matching join indexes were found. inserting into the join index using any common spool files 

If so, control transfers to Block 408; otherwise, if none were identified for this join index in FIGS. 4A and 4B. If the join 

found, this join index is marked as not eligible for common index is defined by a common join, the join index has 

join processing and control returns to Block 400. already been materialized in a common spool and no addi- 

Block 408 represents the RDBMS removing, from the set 40 tional processing is needed here to materialize the join 

of join indexes found in Block 404 above, any join index index. 

where the use of this common join will prevent the join Block 506 represents the RDBMS performing a merge 

index from sharing a common join with a larger number of step t0 me j om rows mt0 the join index, 

tables with another join index. Block 408 also represents the B!ock m sents the RDB MS removing non-matched 

RDBMS removing, from the set of join indexes, any join rQWS from me join index> tf the base Mq ^ aQ innef uble 

indexes that have conflicting outer join terms. Thereafter, the logic terminates. 

Block 410 is a decision block that represents the RDBMS filock 51Q nls loe rdBMS materializing rows for 

determining .whether ^any join indexes are left. If so, control deleU from ^ join Mcx u&[ commQD { fifcs 

transfers to Block 412; otherwise, if there are no join indexes 5Q fof ^ jom ^ m mG$ 4A afld 4R Jf ^ joifl 

that can use this common join, the join index is marked as Mex fc defined b a common joi ^ join {ndex ^ 

00 b, t So 0° f COmm ° n pr0CeSSmg aDd C0Dlr01 relUmS already been materialized in a common spool and no addi- 

to Block tiona | process j ng ^ needed here to materialize the join 

Block 412 represents the RDBMS setting the term list for mdex 

die common join, wherein the term list is the list of terms 55 filock $n eots the RDBMS deletin the join rows 

from the join index found in Block 400, as well as all the r. . . • , , 

* . . r , e I, ■ . . • . from the join mdex. 

unique outer join terms found from all the join indexes that _. . * . . „~„ wc , • » 

. M J . . J Block 514 represents the RDBMS adding non-matched 

share the common join. , . . \ , . f . , , . . t . , . b . . . 

„. . „ . . „™wr, • ._ i- rows to lne J 0lD index, if the deleted table is an inner table 

block 414 represents tne KUbM* removing the term list of ^ . . [nd ^ ^wtor, the 

lode terminates. 

from the residual term list of all the join indexes that share 60 

the common join. CONCLUSION 

Block 416 represents the RDBMS adding "not null" terms This concludes the description of the preferred embodi- 

for each join index that is not defined with the outer join term ment of the invention. The following paragraph describes an 

used to build the common join. alternative embodiment for accomplishing the same inven- 

There after, control transfers to FIG. 4B via "A". 65 tion. 

Referring to FIG. 4B, Block 418 represents the RDBMS In one alternative embodiment, any type of computer, 

reconstructing the joined table list for the common join. such as a mainframe, minicomputer, or personal computer, 
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could be used to implement the present invention. In 
addition, any database management system (DBMS) that 
performs join operations or uses join indexes could benefit 
from the present invention. 

In summary, the present invention discloses a method, 
apparatus, article of manufacture, and data structure related 
to the maintenance of a plurality of join indexes. The join 
indexes are defined for a table stored in the database. The 
join indexes are updated to reflect any updated records 
stored in the table, wherein one or more common joins are 
identified among the join indexes, each of the common joins 
are materialized only once in a common spool file, and the 
common spool file is used to materialize one or more rows 
for updating the join indexes. 

The foregoing description of the preferred embodiment of 
the invention has been presented for the purposes of illus- 
tration and description. It is not intended to be exhaustive or 
to limit the invention to the precise form disclosed. Many 
modifications and variations are possible in light of the 
above teaching. It is intended that the scope of the invention 
be limited not by this detailed description, but rather by the 
claims appended hereto. 

What is claimed is: 

1. A method of optimizing retrieval of data from a 
database in a computerized database management system, 
comprising: 

(a) updating one or more records stored in a table in the 
database; and 

(b) updating a plurality of join indexes defined for the 
table to reflect the updated records stored in the table, 
wherein one or more common joins are identified 
among the join indexes, each of the common joins are 
materialized only once in a common spool file, and the 
common spool file is used to materialize one or more 
rows for updating the join indexes. 

2. The method of claim 1, wherein the updating step 
comprises: 

(1) collecting information about join conditions for the 
join indexes; 

(2) analyzing the join conditions to identify the common 
joins; 

(3) materializing the common joins in the common spool 
file; and 

(4) updating the join indexes using the rows materialized 
from the common spool file. 

3. The method of claim 2, further comprising repeating 
steps (l)-(4) for a next smallest common join. 

4. A computerized database management system for opti- 
mizing retrieval of data from a database, comprising: 

(a) logic, performed by the database management system, 
for: 

(1) updating one or more records stored in a table in the 
database; and 

(2) updating a plurality of join indexes defined for the 
table to reflect the updated records stored in the table, 
wherein one or more common joins are identified 
among the join indexes, each of the common joins 
are materialized only once in a common spool file, 
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and the common spool file is used to materialize one 
or more rows for updating the join indexes. 

5. The system of claim 4, wherein the logic for updating 
comprises logic for: 

5 (i) collecting information about join conditions for the 
join indexes; 

(ii) Analyzing the join conditions to identify the common 
joins; 

(iii) materializing the common joins in the common spool 
file; and 

(iv) updating the join indexes using the rows materialized 
from the common spool file. 

6. The system of claim 5, further comprising logic for 
15 repeating the logic (i)-0 v ) f° r a next smallest common join. 

7. An article of manufacture embodying logic for per- 
forming a method of optimizing retrieval of data from a 
database in a computerized database management system, 
the method comprising: 

20 (a) updating one or more records stored in a table in the 
database; and 

(b) updating a plurality of join indexes defined for the 
table to reflect the updated records stored in the table, 
wherein one or more common joins are identified 
25 among the join indexes, each of the common joins are 
materialized only once in a common spool file, and the 
common spool file is used to materialize one or more 
rows for updating the join indexes. 

8. The article of manufacture of claim 7, wherein the 
30 updating step comprises: 

(1) collecting information about join conditions for the 
join indexes; 

(2) analyzing the join conditions to identify the common 
35 j° ms; 

(3) materializing the common joins in the common spool 
file; and 

(4) updating the join indexes using the rows materialized 
from the common spool file. 

40 9. The article of manufacture of claim 8, further compris- 
ing repeating steps (l)-(4) for a next largest common join. 

10. A data structure stored in a memory for use by a 
database management system executed by a computer, the 
data structure comprising a common spool file used to 

45 maintain a plurality of join indexes defined on at least one 
table stored in the database, wherein the plurality of join 
indexes are updated to reflect updated records stored in the 
table, by identifying one or more common joins among the 
join indexes, by materializing each of the common joins 

50 only once in the common spool file, and by using the 
common spool file to materialize one or more rows for 
updating the join indexes. 

11. The data structure of claim 10, wherein information is 
collected about join conditions for the join indexes, the join 

55 conditions are analyzed to identify the common joins, the 
common joins are materialized in the common spool file, 
and the join indexes are updated using the rows materialized 
from the common spool file. 

+ + * * * 
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